Skip to content

Composer plugin tasks not executed using the PHP version Composer is invoked with #1170

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
echernyavskiy opened this issue Apr 11, 2025 · 4 comments · May be fixed by #1171
Open

Composer plugin tasks not executed using the PHP version Composer is invoked with #1170

echernyavskiy opened this issue Apr 11, 2025 · 4 comments · May be fixed by #1171

Comments

@echernyavskiy
Copy link
Contributor

Given:

  • two PHP versions installed side by side - 8.2 and 8.3
  • /usr/bin/php invokes PHP 8.2 (managed via alternatives), so that's the default version
  • Composer is explicitly invoked with PHP 8.3, i.e. /usr/bin/php8.3 ./composer.phar install

In this setup GrumPHP git:init and configure scripts are executed using PHP 8.2 because the plugin calls vendor/bin/grumphp directly instead of using the PHP binary Composer is using for the current invocation.

I'm not familiar with Composer Plugin API enough to tell if Composer exposes internally the PHP binary it was invoked with. However it looks like there is @php syntax for scripts that does something similar to what ${MAKE} would do in a Makefile, so Composer must maintain some sort of reference to the current PHP binary.

@veewee
Copy link
Contributor

veewee commented Apr 11, 2025

Thanks for reporting @echernyavskiy.

The composer plugin is currently indeed not taking into account what PHP version you are executing with.
See

private function runGrumPhpCommand(string $command): void
on how this works.

Care to take a dive into the code and craft a PR that fixes this?

@echernyavskiy
Copy link
Contributor Author

@veewee, yeah, that's the file I was looking at, and that's how I arrived at the conclusion above.
Any pointers on how to approach this? Like I said I'm not familiar with the Composer Plugin API.

@veewee
Copy link
Contributor

veewee commented Apr 11, 2025

@echernyavskiy It boils down to scrolling through the files in composer/composer.

  • vendor/composer/composer/src/Composer/EventDispatcher/EventDispatcher.php
  • getPhpExecCommand()
  • It seems to be just using '\Symfony\Component\Process\PhpExecutableFinder' (but with additional logic)

The plugin has been created a long way back. Since then, composer has changed a lot.
it might make sense to re-evaluate how it works at some point.
Here's for example a snippet on how it could be done by using composer dependencies only:

$composer = $event->getComposer();
$loop = $composer->getLoop();
$command_executor = $loop->getProcessExecutor();

$command_executor->executeTty(implode(' ', [
    (new PhpExecutableFinder())->find(),
    ...array_map(static fn(string $argument): string => ProcessExecutor::escape($argument), [
        $this->detectGrumphpExecutable(),
        'arg...'
    ]),
]));

Full example

(it should probably contain some additional logic for Windows and .exe support)

@echernyavskiy
Copy link
Contributor Author

@veewee from what I can tell PhpExecutableFinder already handles PHP on Windows, so my PR is pretty concise: #1171.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants